home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Feb 91 / MacApp.Tech$ 2⁄22⁄91 / 2985-Healing the MacApp⁄C-Feb91 < prev    next >
Encoding:
Text File  |  1991-03-06  |  4.4 KB  |  84 lines  |  [TEXT/GEOL]
  1. Item    9511310                         16-Feb-91        11:35PST
  2.  
  3. From:   ALGER                           Alger, Jeff,VCA
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. ------------------------------------------------------------------------------
  8.  
  9. Sub:    Healing the MacApp/C++ rift
  10.  
  11. Fellow MacAppers,
  12.  
  13. I have deliberately waited awhile before reacting publicly to "the C++ MacApp
  14. thing," as George Bush might have called it.  There have been a lot of very
  15. sharp insights shared since the news broke in Phoenix, so allow me to summarize
  16. what I see as points of general consensus, sprinkled with my own observations.
  17. Hopefully, this can help build a coherent strategy for how to proceed from
  18. here.
  19.  
  20. • The whole issue was introduced in an unfortunate way.  Granted, it was
  21. probably easier to plunge ahead with what was perceived as a necessary change
  22. than to deal with preemptive public critism, but even so the word "bombshell"
  23. is not inappropriate in describing the manner of introduction.  This, after
  24. all, is a community that has remained loyal through inadequate staffing of the
  25. MacApp team, interminable delays in releases, numerous "betas" that change
  26. rather dramatically from one version to the next rather than simply fix bugs,
  27. inadequate documentation, and other hardships.  We all know that MacApp is
  28. worth the wait and the effort.  There is nothing to fear in advance discussion
  29. of even controversial subjects in this particular community.  Instead, at a
  30. time when everyone should be formulating strategies to use the great features
  31. of MacApp 3.0, we have had rumors, intrigue, and rebellion.
  32.  
  33. • MacApp 3.0 does, indeed, look like a leap forward.  Lost in the language wars
  34. has been appropriate notice of the great strides made by the MacApp team.
  35.  
  36. • The abrupt switch to C++ will, in fact, cause hardships in certain circles.
  37. Some are affected by the language switch, many by the perceived need to drop
  38. the Think environment.  It is not yet clear the extent of this hardship and the
  39. good folks at Apple are hard at work gathering precisely that information.
  40. However, this again is information that should have been taken into account
  41. before the announcement, not gathered afterwards.
  42.  
  43. • The ultimate change to C++ surprised no one that I know of, including diehard
  44. Pascal fans.  We all recognize business realities, and if Macs are to become
  45. popular in corporate circles, thereby increasing the available market for all
  46. of us, C++ will have to be an integral part of the reason.
  47.  
  48. • Yes, it is a laudable goal to not release source or ever worry about it.  If
  49. object-oriented systems software is ever to become a commercially viable
  50. industry, companies that invent great software will need to protect it.
  51. Furthermore, having a class library which is usable without source indicates a
  52. high degree of discipline in its construction, quality documentation, and
  53. stability of the class hierarchy.  Put another way, by building for a
  54. source-free environment, you create better software.
  55.  
  56. • HOWEVER, no one knows today how to adequately document object-oriented
  57. systems to the extent needed for a source-free MacApp.  Furthermore, no one
  58. really knows how to design stable class hierarchies without resorting to lots
  59. of real-world hammering, and the MacApp team, for all their tremendous
  60. achievements, has not established a track record of bug-free or almost bug-free
  61. software (yet).  This is not a knock at the MacApp team; done properly, quality
  62. assurance on a 50,000+ line MacApp 2.0.1 is probably a comparable effort to QA
  63. on a 1,000,000+ line program in most other arenas.  Object-oriented technology
  64. today is a curious mixture of ancient tradition and infancy.
  65.  
  66. The upshot of all this can be summarized into these points:
  67.  
  68. • The switch to C++ is inevitable.  The questions are how and when, not if.
  69. • Regardless of language, MacApp 3.0 is going to be a great benefit to
  70. everyone.
  71. • Apple needs to do some damage control with those who will be impacted.
  72. Loyalty cuts both ways, and the MacApp community has been intensely loyal to
  73. Apple over the years.  This could be done by maintaining 3.0 in Pascal, whether
  74. exclusively or not, or by speeding the development of Apple and third party
  75. Pascal products that will be C++ friendly.
  76. • Source code will continue to be needed until better documentation is
  77. available and code quality, measured by stability and lack of bugs, is
  78. increased.
  79. • In the future, Apple needs to keep to its tradition of open discussion.
  80.  
  81. Regards,
  82. Jeff Alger
  83.  
  84.